﻿Game Concept: The Eye and The Burden
The game is an asymmetrical multiplayer race where one player becomes a colossal living Eye and all other players become Runners trapped inside a giant dollhouse-like obstacle course.
The entire level is presented as a massive cutaway structure, like a living castle with its front wall removed. Every room, corridor, platform, and obstacle is visible from the outside.
The Eye exists outside the structure.
The Runners exist inside it.
Both sides play in first-person.
The Eye is not a sniper holding a weapon. The Eye itself is a giant living creature. It floats outside the castle, scanning rooms, corridors, and exposed pathways while searching for movement. Because the structure is too large to observe all at once, the Eye must constantly pan across the castle, deciding where to focus its attention.
When the Eye finds a target, it fires devastating laser beams directly from its pupil.
The Runners are trying to reach the exit.
However, they are not simply racing.
Throughout the castle are powerful movement tools, treasures, relics, weapons, gadgets, and resources. Every item has weight.
Weight is the central mechanic of the game.
The more weight a Runner carries, the slower they become.
As weight increases, movement abilities gradually disappear.
A lightly equipped Runner can:
* Sprint
* Dash
* Double jump
* Wall jump
* Grapple
* Air dash
* Chain movement abilities together
A moderately burdened Runner may lose:
* Air dash
* Double jump
* Grapple range
A heavily burdened Runner may lose:
* Dash entirely
* Advanced parkour abilities
* Significant movement speed
A Runner carrying excessive weight becomes little more than a walking target.
This creates a constant risk-versus-reward decision.
Do you travel light and reach the exit safely?
Or do you become greedier, collecting more valuables and stronger tools while accepting that every kilogram makes escape harder?
The Eye exploits this system.
Fast runners are difficult to track and hit.
Heavy runners become predictable.
The Eye constantly watches for signs of greed.
A runner overloaded with treasure may possess powerful equipment but lacks the mobility required to survive direct observation.
The tension of the game comes from this conflict:
The runners want more power.
The runners want more treasure.
The runners want better movement tools.
But every advantage has weight.
Every item makes escape harder.
Every treasure makes the Eye's job easier.
A successful Runner feels like a thief escaping with just enough loot to be worth the risk.
A successful Eye feels like an all-seeing predator patiently waiting for greed to slow its prey.
The game is fundamentally about movement, observation, and burden.
The Eye controls space through vision.
The Runners control space through mobility.
Weight determines which side gains the advantage.

Technical Systems Architecture and Game Design Specification: I-STALK
Production Paradigm and Architectural Directives
The development of asymmetrical multiplayer experiences inherently introduces complex balancing and networking challenges, which are significantly exacerbated when constrained by an aggressive two-month production timeline. The "I-STALK" project fundamentally rejects computationally expensive and time-consuming paradigms, specifically dynamic lighting and shadow-mapped stealth systems, in favor of physical, geometry-based line-of-sight interruption. The core aesthetic and mechanical framework is defined by an ominous, retro-gothic "Dollhouse Castle," wherein the exterior wall is entirely removed. This permits the asymmetrical antagonist—designated as the "Eye"—to observe the macro-map from a two-dimensional side-view perspective, while protagonist "Runners" navigate a three-dimensional interior space possessing Z-axis depth.
To achieve a highly replayable parkour-extraction loop within the stringent developmental timeframe, the software architecture must adhere strictly to a tool-driven, modular philosophy. The programmatic foundation is entirely divorced from hardcoded map layouts, rigid item placements, scale values, or explicit positional vectors. The codebase is engineered exclusively to generate robust developer tools, empowering the human designer to construct, populate, and balance the spatial logic physically within the engine's editor environment. This paradigm shifts the engineering burden from level construction to systems architecture, ensuring that rapid iteration can occur without necessitating continuous codebase compilation or script modification.
Developer Tooling and Modular Data Frameworks
The foundational mandate for the software architecture is the absolute decoupling of gameplay data from systemic logic. This is achieved through a comprehensive suite of custom editor tools, heavily reliant on Unity's ScriptableObject architecture, SerializedObject parsing, and custom Inspector windows. By utilizing memory-efficient data containers, the project allows designers to create new mechanical entities simply by instantiating new assets within the project hierarchy.
ScriptableObject Database Architecture
The architecture utilizes ScriptableObject classes to define the parameters of all interactive elements, ranging from procedural generation modules to the internal economy of the match. This approach prevents data duplication across scenes and provides a centralized location for rapid balance adjustments.
System Component
	ScriptableObject Class Implementation
	Core Exposed Variables and Methods
	Designer Functionality
	Loot and Economy
	ItemData_SO
	itemName, dreadCost, prefabReference, activationDelegate
	Permits the creation of new tools (e.g., Grappling Hook, Ocular Paint) by assigning physical prefabs and defining the loot extraction thresholds required for acquisition.
	Antagonist Abilities
	TrapData_SO
	trapIdentifier, dreadCost, effectRadius, duration, vfxPrefab
	Facilitates the balancing of the Eye's area-of-effect traps and the calibration of resource economy regeneration rates.
	Procedural Topology
	RoomNode_SO
	roomIdentifier, dimensions (Vector3Int), connectionTags (List<String>)
	Defines the volumetric constraints of a localized prefab and the discrete ruleset dictating its connectivity to adjacent spatial modules.
	Match Parameters
	GlobalRules_SO
	extractionLootThreshold, baseDreadRegeneration, matchTimeLimit
	Centralizes all mathematical constants governing the pacing of the extraction loop for swift, comprehensive balance passes.
	Custom Inspector Interfaces and Scene Visualization
Beyond passive data containers, the project necessitates active editor tooling. A custom "Dollhouse Constructor" editor window must be developed. This interface parses all available RoomNode_SO assets, allowing the level designer to define probability weights, maximum spawn counts (e.g., ensuring only a single "Dungeon" module spawns per instance), and valid connection permutations.
To bridge the gap between abstract data and physical space, Editor scripts must leverage OnDrawGizmos and Handles to project the bounding boxes and connection vectors of room prefabs directly into the Scene view1. By rendering color-coded spheres or directional arrows at connection tags (Up, Down, Left, Right), designers can visually verify that the local coordinates of connection points align precisely with the procedural grid stitching logic prior to runtime execution1. Furthermore, OnValidate() hooks within the MonoBehaviour scripts ensure that any modifications to scale or positioning in the Inspector instantaneously update the physical colliders and interaction trigger volumes, eliminating the need to enter Play Mode to test basic spatial relationships.
Procedural Map Generation: The Dollhouse Stitching Algorithm
The macro-map is dynamically synthesized at the initialization of each match. Because the perspective mimics a cross-sectional dollhouse, the generation algorithm operates primarily on an X/Y planar grid, although the prefabs themselves contain Z-axis depth for Runner maneuverability. To satisfy the two-month deadline, the map relies entirely on a modular prefab system, stitched together procedurally utilizing a localized connection-tag architecture.
The Room Connector Paradigm and Constraint Evaluation
Level designers author discrete room prefabs (e.g., Library, Kitchen, Dungeon) and affix empty GameObjects—tagged as "Connectors"—to the extremities of the room's bounds. Each connector possesses a localized directional tag governing the permissible flow of the maze: Up, Down, Left, or Right.
The algorithmic implementation for the procedural generation sequence operates through multiple distinct analytical passes, heavily inspired by constraint-solving algorithms such as the Wave Function Collapse (WFC) and Depth First Search (DFS) traversal methodologies2. The system avoids complex programmatic terrain generation in favor of snapping meticulously designed human assets into unpredictable configurations.
1. Initialization and Root Placement: The algorithm selects a predefined "Starting Area" room—often the Runner spawn sector—and instantiates it at the global origin (0,0,0). The open connection tags inherent to this root module are serialized and added to an active processing queue5.
2. Grid Stitching and Vector Alignment: The algorithm iterates through the open connection queue. For an open "Right" connection, it queries the pool of available RoomNode_SO assets for any room possessing an open "Left" connection. The physical translation required to align the two connection points is calculated by subtracting the local position of the candidate's "Left" connector from the global position of the active "Right" connector.
3. Volumetric Overlap Testing: Prior to formal instantiation, the algorithm must guarantee that the candidate room will not intersect with existing geometry. By calculating the prospective bounding box and executing an Axis-Aligned Bounding Box (AABB) intersection test—or utilizing Physics.OverlapBox—the system evaluates spatial validity. If an overlap is detected, the candidate is discarded, and an alternative configuration is evaluated. This ensures a non-Euclidean overlap never corrupts the physical integrity of the Dollhouse6.
4. Seam Sealing and Boundary Capping: Once the requisite number of rooms is spawned, or the grid reaches the maximum permissible integer dimensions defined in the GlobalRules_SO, the algorithm performs a final traversal. All remaining open connections are capped with solid wall prefabs or dead-end architectural elements to prevent Runners from breaching the map boundaries.
Advanced Topological Considerations: Triangulation and Corridors
While a strict tag-matching system generates functional mazes, ensuring high replayability requires deeper topological variation. The system incorporates secondary algorithms to manage complex spatial relationships, ensuring that the map does not simply branch endlessly into dead ends.
To create cycles and interconnected loops—crucial for stealth evasion—the system utilizes a simplified Minimum Spanning Tree (MST) and Delaunay triangulation logic6. After the primary rooms are placed arbitrarily within the grid constraints, the algorithm evaluates the spatial gaps between unconnected nodes. If two disparate rooms possess facing connection tags but are separated by empty grid space, the system utilizes an A* (A-Star) pathfinding algorithm to plot a route between them6. It then instantiates standardized "Corridor" prefabs along this path, creating highly variable connective tissue between major anatomical sectors of the castle7.
Prop Densification and Procedural Interiors
To support the geometric stealth mechanics, the interiors of the generated rooms must be densely populated with both static and dynamic props. Relying on hand-placed props within the prefabs would result in predictable sightlines. Therefore, the architecture implements a sub-spawner system nested within the room modules9.
Designers distribute "Prop Spawner" nodes across the floor plan of the prefabs. At runtime, these nodes evaluate their localized coordinates, inherit a random global seed, and utilize Perlin noise or weighted probability arrays to instantiate objects such as bookshelves, towering debris, and grand tables1.
Prop Classification
	Algorithmic Distribution Method
	Systemic Functionality
	Static Environmental
	Weighted Randomization
	Permanent LoS obstruction; provides baseline architectural density.
	Dynamic Interactable
	Boolean Toggle Array
	Flipped or pushed by Runners to alter the real-time navigational mesh and stealth geometry.
	Hazardous Physics
	Perlin Noise Clustering
	Fragile objects that generate "Dread" currency for the Eye if disturbed by Runner momentum.
	Crucially, specific environmental objects are assigned a DynamicCover layer. These interactables allow Runners to actively manipulate the spatial geometry. For example, a Runner can interact with a large dining table, initiating a physics calculation that rotates the object 90 degrees on its local X-axis. This instantly generates a vertical physical barrier, severing the Eye's targeting laser and altering the tactical layout of the room.
Geometric Stealth and Line-of-Sight Architecture
The foundational pillar of the game's optimization strategy is the total exclusion of real-time shadow casting, volumetric fog rendering, and light-bounce calculations for stealth determination. In the "I-STALK" architecture, stealth is fundamentally a binary state calculated entirely via spatial physics. If a physical collider interrupts the mathematical vector between the Eye's camera perspective and the Runner's localized transform, the Runner is definitively hidden.
Raycast Implementation Framework and Vector Mathematics
The line-of-sight (LoS) detection is governed by highly optimized vector mathematics utilizing Unity's standard 3D raycasting API. Because the macro environment is evaluated from a 2D side perspective but contains vital Z-axis depth for evasion, standard Physics.Raycast is mandated over Physics2D.Raycast to accurately calculate the occlusion of 3D volumetric assets11.
To ensure real-time performance while the Eye continuously sweeps the macro-map, the system relies on a multi-tiered evaluation sequence before casting computationally expensive physics rays:
1. Camera Frustum Culling: The system continuously evaluates the projection matrix of the Eye player's camera. Using GeometryUtility.CalculateFrustumPlanes, it checks if the bounding box of any active Runner intersects the view frustum. If a Runner is outside the camera's rendering bounds, all subsequent calculations are bypassed, and the Runner is automatically assigned a dormant "Unseen" state13.
2. Square Magnitude Distance Check: For Runners within the active frustum, the system calculates the distance between the Eye's origin and the Runner. By utilizing Vector3.sqrMagnitude, the system culls distant objects rapidly without invoking the processor-heavy square root operations inherent to standard Vector3.Distance calculations14.
3. Multi-Point Anatomical Raycasting: A single raycast projected from the Eye to the center of the Runner's transform is insufficient for rigorous gameplay. A Runner partially obscured by a bookshelf might have an arm or leg protruding, which, under a single-ray system, would incorrectly register them as hidden, creating severe dissonance between the visual presentation and the systemic state13. Therefore, the system projects multiple simultaneous rays from the Eye's origin (the pupil) to predefined anatomical sockets on the Runner's rig: the Apex (Head), Center of Mass, Left Extremity, and Right Extremity13.
If any of these localized raycasts return an uninterrupted vector to the Runner, the stealth state is broken, and the Eye receives targeting feedback.
To guarantee frame-rate stability, the Physics.RaycastNonAlloc method is employed across the codebase12. This populates a pre-allocated array of RaycastHit objects in memory, preventing the continuous generation of garbage collection spikes during the per-frame observation checks. Furthermore, layer masks are strictly enforced via bitwise operations. The raycasts are configured to intersect exclusively with the EnvironmentProp and Runner physics layers, completely ignoring interaction triggers, invisible camera volumes, and decorative background geometry that lacks physical substance12.
The Physics of Stealth Evasion and Prop Destruction
The reliance on geometric colliders ensures that the stealth mechanics function instantaneously without requiring complex recalculations of global illumination grids. When a Runner interacts with the environment to create cover, the physics engine updates the orientation of the object's BoxCollider or MeshCollider. Because the Eye's raycasts evaluate against the immediate real-time state of the physics scene, the line of sight is broken the exact frame the object achieves its new rotation.
However, physical cover in "I-STALK" is not invulnerable. If the Eye player holds the primary fire input to charge the "Main Laser," the system projects a predictive indicator line using a LineRenderer component. If this telegraphed line intersects a valid EnvironmentProp collider—such as a flipped table shielding a Runner—the systemic logic initiates a localized destruction sequence.
The prop incurs systemic damage over a brief, variable delay parameter (configurable via the GlobalRules_SO). This delay provides the Runner a micro-window of reaction time to abandon the cover. Upon expiration of the delay, the system executes a total destruction protocol, disabling the mesh renderer and the physics collider simultaneously, and instantiating a localized particle effect. This instantly strips away the geometric barrier, exposing the Runner to subsequent multi-point raycasts and forcing constant spatial repositioning.
Runner Systems: Kinetics, Agility, and the Economic Loop
The mechanical identity of the protagonist Runners is defined by extreme fragility juxtaposed with hyper-mobility and continuous risk assessment. The objective is to navigate the Z-axis depth of the corridors to avoid the Eye's orthographic gaze while pushing aggressively along the primary X/Y axes to harvest scattered valuables and extract via procedural Altars.
Advanced Mobility Kinetics and Physics Manipulation
The Runner controller is a bespoke, physics-driven character motor that prioritizes aerial control, momentum retention, and spatial manipulation. To bypass slow vertical climbs or quickly traverse exposed exterior bridges where physical cover is procedurally sparse, the system implements a suite of advanced parkour mechanics:
* Base Locomotion: The standard run, jump, and slide mechanics are governed by directly manipulating the velocity vectors of the Runner's Rigidbody, bypassing Unity's standard CharacterController for tighter physics integration. Sliding temporarily alters the dimensions of the Runner's capsule collider, compressing its Y-axis value to allow passage under low geometric obstacles while simultaneously shrinking the raycast target profile presented to the Eye.
* Wall-Jumping and Aerial Dashing: Calculated by casting short, localized rays laterally from the Runner's bounding box. If these rays detect vertical surfaces tagged as EnvironmentProp, the systemic gravity scale is dynamically attenuated, allowing the Runner to cling or slide down the surface. A subsequent jump input applies a perpendicular impulse force, utilizing Rigidbody.AddForce(Vector3, ForceMode.Impulse), enabling rapid zigzagging ascents between narrow procedural corridors.
* The Grappling Hook: Driven by the open item system, the hook fires a physics projectile. Upon striking a surface tagged as Grappleable, the system calculates a Bezier curve between the anchor point and the Runner. It then applies a high-velocity localized force to the Rigidbody, effectively suspending standard gravity calculations for the duration of the traversal, allowing rapid vertical repositioning to evade the Eye's targeting laser.
The Shrine Economy and the Open Item System
The acquisition of loot within the Dollhouse serves a dual systemic purpose: it acts as the quantitative victory metric (the threshold required to activate the endgame extraction sequence) and functions as an active, in-match currency. This dual utility forces a constant psychological tension between hoarding wealth for victory or expending it for survival.
Randomly distributed throughout the procedural map generation phase are "Shrines." These spatial entities act as localized, highly dangerous storefronts, as they are often placed in areas with limited physical cover. When a Runner interfaces with a Shrine trigger volume, the UI populates defensive and traversal items dynamically queried from the central ItemDatabase_SO framework.
The technical implementation of these items relies heavily on manipulating the line-of-sight algorithms and rendering pipelines:


Item Identifier
	Systemic Function
	Technical Implementation Protocol
	Ocular Paint
	Counter-Intelligence
	The Runner executes a short-range raycast to detect any environmental prop residing on the IncarnationTarget layer (e.g., portraits, statues). Upon interaction, it modifies the prop's internal state boolean to isPaintBlinded = true. This explicitly locks the Eye's ability to transition its camera perspective to this localized coordinate.
	Mirror / Flashlight
	Defensive Disruption
	Projects a volumetric, cone-shaped mesh procedurally15. If this localized field-of-view mesh intersects the Eye's macro-pupil coordinates or an actively possessed prop, it triggers a screen-space Post-Processing volume overlay exclusively on the Eye player's client. This raises the exposure and bloom values to maximum, effectively whiting out their screen for 2–3 seconds.
	Grappling Hook
	Traversal Vectoring
	Bypasses standard kinetic limitations by instantiating a physical tether. Modifies the Runner's Drag parameters to allow for swinging arcs over exposed courtyard sectors, vastly reducing the time spent outside of geometric cover.
	The core systemic tension arises directly from this economic choice. The Runner must dynamically calculate risk: expending collected loot to acquire a Mirror or Ocular Paint drastically increases survivability during the next hazardous corridor crossing, but it mathematically delays reaching the extraction threshold, prolonging their exposure in the match.
The Eye: Observation, Incarnation, and Asymmetrical Trapping
The asymmetrical antagonist operates on an entirely disparate control paradigm and psychological wavelength. The Eye player does not engage in traditional traversal; rather, they play a game of macroscopic observation, resource management, and precise execution. The Eye continuously pans an orthographic or low-FOV perspective camera across the dollhouse, relying on human perception to detect micro-movements or the sudden physics displacement of flipped tables.
The Main Laser Mechanics and Telegraphing
The Eye's primary offensive tool is a charged, highly lethal energy beam. The technical implementation of the laser relies heavily on predictive telegraphing to ensure fairness and provide the Runners with actionable evasion windows.
When the Eye initiates the charge input, several localized systems activate simultaneously:
1. Audio Modulation: An audio source attached to the Eye's transform plays a localized, escalating pitch, mapped to the charge percentage variable.
2. Visual Telegraphing: A semi-transparent, low-alpha LineRenderer is drawn continuously from the Eye's global origin to the current cursor coordinate mapped onto the Z-depth plane of the procedural rooms.
3. Execution and Vaporization: Once the arbitrary charge threshold is met, the system executes a Physics.SphereCast (a volumetric, thick raycast) along the telegraphed vector. Utilizing a sphere cast rather than a standard raycast ensures that the Eye does not miss due to pixel-perfect inaccuracies, providing a generous hit-box. If the sphere cast intersects a Runner's collider, an instant vaporization sequence is triggered, eliminating the player from the instance. If it strikes physical cover, the delayed destruction protocol (detailed in Section 4.2) is initiated.
The Incarnation System: Bypassing Geometric Occlusion
Because the Eye's macro-perspective is fundamentally constrained by the side-view projection, it cannot observe the Z-axis space located physically behind large procedural props. A Runner hiding securely behind a massive bookshelf is entirely safe from the exterior gaze. To counter this, the architecture implements the "Incarnation System," acting as the primary infiltration mechanism.
The Eye possesses the systemic capability to "possess" specific, intricately decorated environmental objects seeded throughout the generation phase—specifically, props adorned with eyes, such as aristocratic portraits, stone gargoyles, or mounted animal heads.
The technical execution of this ability relies on dynamic camera perspective shifts and material manipulation:
* The Perspective Shift: When the Eye targets a valid IncarnationProp and triggers the ability, the active camera's transform is smoothly interpolated (lerped) or instantaneously snapped from the exterior macro-view to the local coordinate space of the possessed prop inside the room. This effectively grants the Eye a localized, first-person view of the interior, entirely bypassing the geometric cover the Runner is utilizing.
* The Macro Indicator (The Tell): Asymmetrical balance requires that the Runners are visually informed of this infiltration. Upon Incarnation, the giant exterior Eye's central pupil mesh is deactivated via MeshRenderer.enabled = false, leaving a stark, blank white orb hanging outside the castle.
* The Micro Indicator: Simultaneously, the emission channel on the possessed prop's material shader is dynamically increased via code, causing the eyes on the portrait or statue to glow violently. This provides a localized visual cue, warning the Runner that their previously safe physical cover is now compromised from an interior angle.
While incarnated, the Eye sacrifices the macro-view but gains the localized ability to fire a "micro-laser." This mechanic utilizes a fast-acting raycast originating from the prop's forward vector, capable of inflicting minor, non-lethal damage. The systemic purpose of the micro-laser is not to eliminate the Runner, but to force them to abandon their current physical cover and scramble out into the exposed corridors where the exterior macro-laser can vaporize them.
Trap Framework and the Dread Economy
The Eye's area-denial capabilities and psychological warfare tools are driven by the accumulation of a specific resource designated as "Dread." This currency generates passively over time, functioning as a continuous pressure mechanism against the Runners. More importantly, Dread spikes dynamically when Runners make operational errors, such as triggering noise events, sprinting near fragile physics objects, or failing a parkour vault sequence.
The TrapData_SO framework dictates the parameters, costs, and behaviors for the Eye's localized deployments.
Trap Designation
	Systemic Classification
	Technical Implementation Logic
	Sludge / Tar
	Area Denial and Kinetic Debuff
	The Eye raycasts to a valid floor polygon and instantiates a localized, invisible trigger collider. Utilizing OnTriggerEnter, the system intercepts the Runner's kinetic motor. The maximum velocity multiplier is clamped to a severe reduction (e.g., 0.4), and the jump execution function is temporarily locked. This strips the Runner of their agility, making them an easy target for the Main Laser.
	False Chest
	Decoy and Intelligence Gathering
	Instantiated as an exact visual duplicate of high-value procedural loot prefabs. If a Runner's interaction sphere overlaps the trigger, it invokes a Remote Procedure Call (RPC) across the network. This instantaneously pings the exact Vector3 coordinate of the interaction to the Eye player's UI canvas, accompanied by a loud audio cue.
	The ability to place these traps is strictly governed by the Dread economy, requiring the Eye player to make continuous strategic calculations: Do they expend Dread on multiple, cheap intelligence-gathering False Chests to track Runner movements, or do they hoard Dread to choke out vital extraction Altars with highly expensive, mobility-crushing Sludge?
The Core Extraction Loop and Match Pacing
The macro-flow of an I-STALK match is designed as an escalating pressure cooker. The systemic pacing relies entirely on the interplay between the extraction mechanics, the psychological tension of the Hunt, and the persistent meta-currency architecture.
Spawn Dynamics and the Initialization Phase
At the precise moment the procedural map generation algorithm resolves its final corridor connection and overlap check, the server initializes the player entities. The single Eye player is spawned at a fixed, exterior macro coordinate, granting an immediate overview of the Dollhouse. Simultaneously, 1 to 4 Runner players are instantiated at randomized interior spawn points. These points are drawn from a validated pool of SpawnNode transforms nested within the generated rooms, ensuring Runners never spawn within solid geometry or in direct line-of-sight of the exterior wall.
The initial "Hunt Phase" is characterized by rapid, desperate exploration. Runners navigate the Z-axis depth of the corridors, utilizing the physical geometric props to shield their vectors from the Eye's raycasts. The Eye pans the camera, attempting to establish an initial read on the Runners' spawn sector by observing the physics displacement of dynamically pushed objects or the activation of distant Shrine triggers.
The Extraction Phase and Endgame Resolution
As Runners aggressively harvest loot, a localized integer counter tallies their progress on their individual UI canvas. Once a specific Runner surpasses the server-defined extractionThreshold (a variable configured in the GlobalRules_SO), the "Exit Altars" are dynamically activated. These Altars are placed at the absolute procedural extremities of the map during the initial generation phase, ensuring that extracting requires a lengthy, highly dangerous traversal.
The endgame forces a direct, high-stakes confrontation. To extract, the Runner must expose themselves by navigating to an Altar and holding an interaction input to channel a static animation sequence for several consecutive seconds. This channeling phase requires the Runner to remain stationary within a highly specific trigger volume, entirely disabling their parkour mobility and evasion mechanics.
Crucially, the moment channeling begins, the Eye is immediately notified of the specific Altar's activation via a global UI ping, shifting the gameplay loop from a widespread scanning hunt to a highly localized, intense siege. The Eye must immediately focus all observation, trap deployment, and laser targeting on the Altar room to interrupt the extraction.
If the Runner survives the channeling duration without their line-of-sight cover being destroyed and their avatar being vaporized, they are successfully removed from the match space. Any loot accumulated above the required threshold is securely banked as a meta-currency. This currency is serialized and written to the player's persistent profile data, allowing for main-menu progression, cosmetic customization, or the pre-match unlocking of advanced items for subsequent runs.
Conversely, the Eye achieves absolute systemic victory if the array of active Runners is reduced to zero via laser vaporizations prior to any successful extractions occurring.
By strictly adhering to physical, geometry-based colliders for stealth calculations, robust procedural generation algorithms for map longevity, and a comprehensive ScriptableObject architecture for rapid tooling, the two-month production timeline can be aggressively met with minimal debugging overhead. The engineering philosophy guarantees that the human designer can mold the mathematical balance, spatial flow, and economic tension of the game seamlessly, while the underlying codebase remains stable, highly modular, and exceptionally performant.
Works cited
1. Procedural Structures in Unity - DEV Community, https://dev.to/nightsmore/procedural-structures-in-unity-3be4
2. MIT licensed Grid prefab based procedural generation system - Reddit, https://www.reddit.com/r/Unity3D/comments/1n0ezb8/mit_licensed_grid_prefab_based_procedural/
3. Procedural Dungeon Generator in Unity [TUTORIAL] - YouTube, https://www.youtube.com/watch?v=gHU5RQWbmWE
4. Steps to create 3D tiles based dungeon map generator on Unity?, https://www.reddit.com/r/roguelikedev/comments/k16t0r/steps_to_create_3d_tiles_based_dungeon_map/
5. Dungeon generator | Edgar - Unity - GitHub Pages, https://ondrejnepozitek.github.io/Edgar-Unity/docs/generators/dungeon-generator/
6. Procedurally Generated Dungeons - VAZGRIZ, https://vazgriz.com/119/procedurally-generated-dungeons/
7. How to make pathways/corridors in a randomly generated dungeon?, https://gamedev.stackexchange.com/questions/169574/how-to-make-pathways-corridors-in-a-randomly-generated-dungeon
8. A graph based procedural dungeon generator for Unity · GitHub, https://github.com/SolAnna7/TaurusDungeonGenerator
9. Procedural Generation Grid - User Manual, https://www.filipmoeglich.pl/download/Procedural%20Generation%20Grid%20-%20User%20Manual.pdf
10. [RELEASED] Procedural Generation Grid - Unity Discussions, https://discussions.unity.com/t/released-procedural-generation-grid/849158
11. Scripting API: Physics2D.Raycast - Unity - Manual, https://docs.unity3d.com/6000.4/Documentation/ScriptReference/Physics2D.Raycast.html
12. The Power of Raycasting in Unity: Tips, Tricks, and Best Practices, https://medium.com/@learngamestutorial/the-power-of-raycasting-in-unity-tips-tricks-and-best-practices-842937d6acfc
13. How do you create a line of sight for AI? - Unity Discussions, https://discussions.unity.com/t/how-do-you-create-a-line-of-sight-for-ai/64949
14. Check if player is seen by any enemy - Unity Discussions, https://discussions.unity.com/t/check-if-player-is-seen-by-any-enemy/832323
15. Field-of-View Mesh System | Unity C# project by Alexander Larsen, https://alexanderlarsen.com/projects/fov-mesh/